Database and form design are basic components in much of the data being offered and distributed in the art. Of late, simplified approaches to database design the automation of database development and editing and the ability to quickly generate forms for the collection and management of data have become an important aspect of digital data management.
One approach to speed up and simplify the generation of databases and their design is the practise known in the art of designing a form, laying out fields in that form and generating a template for the requirements of the database that is needed behind that design once the form and database go into use. One example of the way this has been done is to generate an XML document that contains the needed field names, types and requirements of a form and using this along with an automation tool to generate the required database to fit the form.
Yet another method as used by the form generator in the Google Documents product is to automate the generation of a database using a simple set of field types and a form format with very limited layout flexibility.
Both of the described methods still use the popular basic database generation methodology of creating tables that contain fields that are of a specific type and that ultimately will contain data related to the fields contained in that table.
The above approaches treat form related data as a hierarchy of information grouped firstly in tables then sub grouped in field names then finally in related data tied to each field name.
These approaches lead to redundancy and inefficiencies when new fields, forms and tables are introduced, or the database is changed over time,
More broadly, there are several ways of storing form data, including:
(a) Data Object
The form content is stored as data file or object, e.g. XML, Lotus Notes database object. If the form data object is stored in a database the field content needs to be indexed to enable the user to query form content.
This approach can easily handle form layout changes, however the content indexes need to be updated when the new form layout is issued.
(b) Form Table
The form content is stored directly in a database table, the table can be form specific, i.e. the table is form specific. Alternatively, the form can be mapped to the larger application data model or schema.
This approach requires changes to the database when the form layout is changed, i.e. to add columns to database tables.
This approach can also it make it difficult to query a collection of records that have different form layouts. (c) Transactional storage: e.g. Oracle forms
The form fields are mapped as database update
transactions, where all field values updates are executed as atomic database transactions, the method is derived from the financial and banking sectors.
While this approach provides a method of extending or handling changes to form layouts, by changing field to data transaction mapping. The mapping changes need to be done by an IT specialist, or programmer
This approach also requires the form to interact with the database when each field is updated.
This approach can also it make it difficult to query a collection of records that have different form layouts.